In the software development lifecycle, software is refined through iterations. In this environment, the testing lifecycle must also have an iterative approach with each build being a target for testing. Additions and refinements are made to the tests that are executed for each build, accumulating a body of tests, which are used for regression testing at later stages. This approach implies that it causes reworking the tests throughout the process, just as the software itself is revised. There is no frozen software specification and there are no frozen tests.

This iterative approach gives a high focus on regression test. Most tests of iteration X are used as regression tests in iteration X+1. In iteration X+2, you would use most tests from iteration X and iteration X+1 as regression tests, and the same principle would be followed in subsequent iterations. Because the same test is repeated several times, it is well worth the effort to automate the tests. It becomes necessary to effectively automate your tests to meet your deadlines.

Look at the lifecycle of testing without the rest of the project in the same picture. This is the way the different activities of testing are interconnected if you view them in a non-iterative view:

The testing lifecycle.

This lifecycle has to be integrated with the iterative approach, which means that each iteration will have a test cycle following that pattern.

 

Execution is both execution of the new tests and regression tests using previous tests.

The testing lifecycle is a part of the software lifecycle; they should start at the same time. The design and development process for tests is as complex and arduous as the application being built. If not started early enough, the tests will either be deficient, or cause a long testing and bug-fixing schedule to be appended to the development schedule, which defeats the goals of iterative development. Furthermore, the test planning and design activities can expose faults or flaws in the application definition. The earlier these are resolved, the lower the impact on the overall schedule. Problems found during evaluation can be solved within this iteration, or postponed to the next iteration. One of the major tasks in evaluation is to measure how complete the iteration is by verifying what requirements have been implemented. There is always some "requirements creep" from iteration to iteration, something you need to be aware of and able to manage.

The ways in which you will perform tests will depend on several factors: your application domain, your budget, your company policy and risk tolerance, and your staff. How much you invest in testing depends on how you evaluate quality and tolerate risk in your particular environment.

Copyright  ⌐ 1987 - 2000 Rational Software Corporation

Display Rational Unified Process using frames

Rational Unified Process